Pipelined network processing with FIFO queues

ABSTRACT

A system and method for operating on data within a network device is described. Between two data operations in a network device is a FIFO queue, which is used to separate the clock domains of the data operations. Data from the first operation is stored in the FIFO queue, which signals an indication to the second operation that there is data in the queue. When the second operation is signaled that there is data in the FIFO queue, it immediately begins reading data from the queue, and begins performing its prescribed operations on the data once it has read enough data from the queue for it to begin operating.

TECHNICAL FIELD

[0001] This disclosure relates to a system for network processing, and,more specifically, to a system including run and stop network processinghaving FIFO queues located between processing stages.

BACKGROUND

[0002] A network processing device uses a series of different stages toprocess incoming and outgoing data packets when the packets are arrivingor are exiting the network device. For example, one stage may handlepacket header processing, another may handle Medium Access Control (MAC)layer processing, yet another stage may handle Point to Point Protocol(PPP) processing and still another stage may handle High Level Data LinkControl (HDLC) processing. Because these different network processingstages receive and process data at different data speeds, oftentimes aseries of controlled First In-First Out (FIFO) buffers or queues areused between the different processing stages to help the data flowsmoothly and timely through the network device.

[0003] Having FIFO queues helps data flow in a timely way through thenetwork device. For example, the presence of a FIFO queue between twoprocessing stages allows the stages to operate in different clockdomains, i.e., to operate at different clock speeds, or to operate withclocks at the same speed but not synchronized to one another. By havinga FIFO queue between stages with different clock domains, stages do notneed to coordinate a data transmission from one stage to another.Instead, after completing its processing, the first stage simplydeposits the packet on which it has just completed processing into theFIFO queue and notifies the second stage that the packet is now presentin the queue. The second stage then retrieves the packet from the FIFOqueue and begins processing the packet. This system uses less time thanif the FIFO queues had to transfer data directly from one to the other.

[0004] A second reason for having FIFO queues between stages is that itis sometimes impossible to synchronize a single clock signal across alarge number of different circuits or stages, due to capacitive loading,signal driving capabilities, etc., and therefore FIFO queues are used toisolate stages and allow them to operate relatively independently fromone another.

[0005] Data arriving at a network processor generally does not arrive atregular intervals and, in fact, may arrive in sporadic chunks. Also,sometimes one or more of the network processing stages can have a shortdelay and data behind that stage becomes blocked. These types of datathroughput inconsistencies can leave packets of data languishing in oneor more of the FIFOs. If the data packets wait too long, the networkdevice may drop one or more of the packets. When one of the stageprocesses has no data packets to process, it stops processing and waitsfor the next packet to be delivered to the FIFO queue, after which itreceives a signal from the previous stage that data has been depositedin the FIFO queue, and the previously stopped stage starts runningagain. For this reason these processes are often called run and stopprocesses, and together the series of processes are known as the run andstop pipeline. These intermittent data transmissions cause delays inprocessing data in the network processing device, and generally lowerperformance of the network device.

[0006] The present invention addresses these and other problemsassociated with the prior art.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007]FIG. 1 is a block diagram of a network device according to anembodiment of the invention.

[0008]FIG. 2 is a block diagram of a FIFO queue used in embodiments ofthe invention.

[0009]FIG. 3 is a block diagram of a network processor according to anembodiment of the invention.

[0010]FIG. 4 is a flow diagram showing actions taken by one of theprocesses shown in FIG. 3.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0011] Embodiments of the invention use a series of FIFO queues, eachplaced between two of many or all of the operational stages within anetwork device, both on the ingress and egress sides of the networkdevice.

[0012] The ingress side of the network device encompasses all of theprocessing to data packets done between the time they are received at aninput port from the data network, such as the Internet, and the timethey are sent to the switch fabric. The switch fabric matches theincoming data packets to their destination output port, and movespackets from the ingress side of the network device to the egress side.The egress side of the network device encompasses all of the processingto the data packets done between the time they are output from theswitch fabric, until the time they are sent back onto the data networkfrom the output port.

[0013] Within each of the sides of the network device, ingress andegress, are a number of stages that perform different processes orfunctions, examples of which are given below. Embodiments of theinvention include FIFO queues located between at least some of theprocesses, where a process that is just finishing sends its data, andwhere a process that is just beginning retrieves its data. The beginningprocess monitors the FIFO queue for the presence of data. Once data isdeposited in the FIFO queue by the finishing process, the beginningprocess retrieves the data immediately, without waiting for anyindication or signal from the finishing process that it deposited datain the FIFO queue. It is also unnecessary that the beginning processretrieve the entire packet of data from the FIFO queue before beginningto process the packet. Instead, once the beginning process has retrievedenough data from the FIFO queue to begin processing, the beginningprocess works on the data, even if the entire packet was not in the FIFOqueue. Indeed, the beginning process may be operating on packet dataretrieved from a FIFO queue while the finishing process is still storingthe packet in the FIFO queue.

[0014]FIG. 1 shows a block diagram of a network system device 100, tomore fully explain the environment in which embodiments of the inventionoperate. The network system device 100 is coupled to a computer network10, such as the Internet. Included in the network device 100 is anetwork processor 20, which is coupled to a switch fabric 40 through aningress buffer manager 30, and an egress buffer manager 50.

[0015] Within the network processor 20 is a series of individual ingressprocesses 22, collectively labeled as 23, and a series of egressprocesses 24, collectively labeled as 25. The series of ingressprocesses 23 encompasses the steps taken to guide packets from the timethey enter the network processor 20 until the time they are transmittedto the ingress buffer manager 30. The ingress buffer manager 30temporarily stores packets of data that are grouped to be sent to thesame output port. The ingress buffer manager 30 may use external storage34 to hold all of the waiting packets. Once the switch fabric 40 isavailable, the waiting packets are retrieved from the buffer manager 30,and sent through the switch fabric 40 where they are received andtemporarily stored by an egress buffer manger 50. Similar to the ingressbuffer manager 30, the egress buffer manager 50 may utilize externalstorage 54 to store packet data. These packets are then sent back to thenetwork processor 20 and through the series of egress processes 25,which encompasses the steps taken to guide the packets from the timethey are retrieved from the egress buffer manager 50, until the timethey are sent out of the network processor 20 and back onto the computernetwork 10.

[0016] Between two adjacent individual ingress processes 22 and egressprocess 24 are FIFO queues 28. As described above, FIFO queues 28 aretemporary buffers used to provide a good method for data deliverybetween two adjacent processes, but not requiring either process tonegotiate directly with the other for the details of data transfer.

[0017] An example of a FIFO queue 28 is shown in FIG. 2. The FIFO queue28 has a data input bus 12 for sending incoming data to a write port 13,and also has a data output bus 17 on which is placed data that isretrieved from a read port 16. Data is written into the FIFO queue 28from an outside source, such as a first ingress process 22, through theinput bus 12 and is read from the FIFO queue by, for instance, a secondingress process 22 through the output bus 17. Data is always written toand read from the FIFO queue 28 sequentially, i.e., the first data to bewritten in the queue is also the first data to be read from the queue.There is no way to read data out of order. Data can be written into theFIFO queue 28 and read from the queue simultaneously, i.e. the readingprocess does not have to wait until the queue is free from being writtento before reading data from it.

[0018] The FIFO queue 28 includes a write pointer 11, and a read pointer15. The write pointer 11 indicates the position of where the next datathat is written into the write port 13 will be stored, and the readpointer 15 indicates the position from where the next data to be readfrom the read port 16 will be retrieved. When the FIFO queue 28 isinitialized, both the write pointer 11 and the read pointer 15 are setto point at the first data location in the queue. For purposes of thisdiscussion, assume that the FIFO queue 28 has 16 data storage locations,numbered S1-S16. Therefore, when the FIFO queue 28 is initialized, boththe write pointer 11 and the read pointer 15 will be pointing to storagelocation S1. Whenever the write pointer 11 and the read pointer 15 arepointing to the same data storage location, the FIFO queue 28 is empty.

[0019] In practice, the FIFO queue 28 can have any number of storagelocations, and is only limited by the size of the physically implementedcircuit. In addition to the number of storage locations in a FIFO queue,called ‘depth’, there are a certain number of bits for each storagelocation, called ‘width’. Common sizes of FIFO queues 28 have a depth ofbetween 64 and 512,000 storage locations, and have a width between 1 and72 bits. The width of FIFO queues is selected to match the size neededby the application. In this description, a width of 32 bits, or 4 bytesis assumed, but embodiments of this invention are operable with FIFOqueues 28 having any width or depth.

[0020] When data is written into the write port 13, it is automaticallystored in the memory location of the FIFO queue 28 pointed to by thewrite pointer 11. For instance, if 16 bytes of data are written into ajust-initialized FIFO queue 28, the data is written into storagelocations S1-S4, and the write pointer 11 will then point to storagelocation S5. If no data has yet been read from the FIFO queue 28, theread pointer 15 will remain pointing at its initial location of storagelocation S1.

[0021] Both the write pointer 11 and the read pointer 15 are circularlists, in that, once they reach storage location S16 (in the examplewhere there are only 16 storage locations), they will automatically loopback to pointing to the first storage location, number S1, without aneed to perform a separate pointer reset.

[0022] Typically, the FIFO queue 28 also has flags to indicate thestatus of data in the queue. A full flag 14, when set, indicates thatthe FIFO queue 28 is full and can accept no more data until some of thedata has been read from the queue. Conversely, an empty flag 19, whenset, indicates that there is no data in the FIFO queue 28 to be read.When neither the full flag 14 nor the empty flag 19 are set, the FIFOqueue 28 contains data. It is impossible for the full flag 14 and theempty flag 19 to be simultaneously set.

[0023]FIG. 3 shows an example series of ingress processes 23 (also knownas the ingress run and stop pipeline 23). To help explain operation ofthe FIFO queues 28 in the network processor 20, assume that there arefive ingress processes 22 in the run and stop pipeline 23. The processes22 are labeled 22A through 22E. There are also 5 FIFO queues 28,numbered 28A through 28E. The first FIFO queue 28A is located betweenthe computer network 10 and the first ingress process 22A. The secondFIFO queue 28B is located between the first ingress process 22A and thesecond ingress process 22B. This progression continues until the lastingress process is reached, 22E, which sends its data directly to theingress buffer manager 30 to be forwarded on to the switch fabric 40.

[0024] When a data packet arrives from the computer network 10, it isimmediately stored in the first FIFO queue 28A. As the data packet iswritten into the FIFO queue 28A, the write pointer 11 increments fromits initial position of S1, and the empty flag 19 immediately changes toindicate that data is present in the FIFO queue 28A, even as the rest ofthe packet is being loaded into the queue. Data from the rest of thepacket and from additional packets will continue to be written from thecomputer network 10 into the FIFO queue 28A as it arrives from thecomputer network 10, until the queue becomes full and can accept no moredata. If the FIFO queue 28A becomes full with data, the full flag 14 ofthe FIFO queue 28 becomes set to signal that no more data can be storedin the queue. In practice FIFO queues are large enough to handle a verylarge amount of data, and only rarely would the first FIFO queue 28A inthe ingress stop and go pipeline 23 be full.

[0025] The first ingress process 22A, which in this example is anEthernet processor, monitors the empty flag 19 of the FIFO queue 28A todetermine when data is stored in the queue. Once data begins to bestored in the FIFO queue 28A, the Ethernet processor 22A immediatelyreads the data from the queue and begins processing the data as soon aspossible. Recall that data can be written to and read from the FIFOqueue 28 simultaneously, so the Ethernet processor 22A can begin readingthe data packet with very little delay. The Ethernet processor 22Abegins processing the packet even if all of the packet data has not yetbeen read from the FIFO queue 28A, or indeed, even if all of the packetdata has not yet been written into the FIFO queue 28A.

[0026] For instance, the Ethernet Processor 22A first parses the headerinformation of the data packet. It is not immediately concerned with thedata in the packet, other than the header data. Therefore, once theheader of the current packet has been read from the FIFO queue 28A, theEthernet Processor 22A can begin its operations of parsing the header,and initiate a destination address lookup in the routing tables, evenbefore the entire packet has been read from the FIFO queue 28A. Recalltoo that the data must be read from a FIFO queue in the same order thatit is written. Therefore, the Ethernet processor 22A need not wait untilall of the data from a single packet has arrived, because it knows thatthe rest of the data will eventually arrive, and is guaranteed to be inorder.

[0027] Once the Ethernet processor 22A has finished processing, itwrites the data into the FIFO queue 28B. Prior to writing the data intothe FIFO queue 28B, the Ethernet processor 22A must check the status ofthe full flag 14 of the queue. If the FIFO queue 28B is full, then theEthernet processor 22A must stop processing, and wait until the queue28B is no longer full. Once the FIFO queue 28B is ready to accept data,the Ethernet processor 22A can then precede writing data to the queue28B.

[0028] Assume instead that the FIFO queue 28B is empty. In that case,the PPP processor 22B continuously monitors the empty flag 19 of theFIFO queue 28B, waiting for data to be written to the queue 28B.Immediately when the Ethernet processor 22A writes data into the FIFOqueue 28B, its empty flag 19 changes to signal that data is in thequeue. This, in turn, signals the PPP processor 22B, which beginsreading the data from the FIFO queue 28B, and begins its processing ofit. As in the case of the Ethernet processor 22A, the PPP processor 22Bneed not wait until the entire packet has been downloaded from the FIFOqueue 28B in order to start processing the packet. Rather, the PPPprocessor 22B can begin processing the data as soon as the necessarydata is read from the FIFO queue 28B. Of course, because differentprocessors 22 process data from different parts of a data packet, oneprocessor 22 may need to download more data from its respective FIFOqueue 28 prior to beginning processing than other processors 22 need todownload. In embodiments of the invention, each of the differentprocessors 22 begin processing the data retrieved from its respectiveFIFO queue 28 as soon as it is able, i.e., as soon as it has enough datato proceed.

[0029] Embodiments of the invention, therefore, unlike prior networkdevices 100 that are limited by the size of the FIFO queues 28, areinstead limited by the bandwidth of the processors 22. For example jumboframes of data can be as large as 10,000 bytes each. If a network device100 has a high number of input ports, then several hundred kilobytes ofmemory may be required to store the incoming packets. Instead of storingall the incoming packets prior to processing them, embodiments of theinvention begin processing them as soon as the processors 22 areavailable, and do not even wait until the entire packet has beendelivered prior to beginning processing. Therefore, in order to preventa network device 100 from having a constantly increasing time lag ofhandling packets, the most complex of the ingress processors 22 and theegress processors 24 must operate faster than the rate at which datapackets arrive at the network device.

[0030] Some of the ingress processors 22 cannot immediately modify thedata on which they are working. For instance, when performing a lookupkey, a request for a lookup may take a relatively long time period toreturn; certainly too long to wait on the response. In thesecircumstances, the ingress processors 22 are able to communicate withone another over a communication line 29 in the network processor 20.Although the communication line 29 is illustrated in FIG. 3 as aseparate line or bus, this figure is only a functional diagram, andcommunication does not necessarily take place over a separate bus.

[0031] By using the communication line 29, data processing can bestreamlined. For instance, if the Ethernet processor 22A performs arouting lookup, the data packet can continue to progress through theprocesses 22B, 22C, etc., before the lookup is sent back to the Ethernetprocessor 22A. The Ethernet processor 22A then places the lookup resultson the communication line 29, and another process, such as 22D or 22Ecan insert the results back into the data packet. In this way, there isno delay by waiting for the response, but rather this parallelism (byperforming the lookup at the same time as other processes are beingperformed) increases the overall bandwidth of the network device 100.

[0032] The communication line 29 also allows an easy way to collectstatistical information on the data packets that are being serviced bythe particular packets in the network processor 20. As a data packet isserviced, a quick write to the communication line 29 allows real-timedata tracking of data in the network processor 20.

[0033]FIG. 4 is a flow diagram showing operations in the individualinput processors 22 of the ingress run and stop pipeline 23. The flowbegins at step 80 where the input process 22 checks the empty flag 19 ofthe previous FIFO queue 28 to determine if any data is stored therein.For instance, the SONET processor 22D would be monitoring the FIFO queue28D. As long as the FIFO queue 28 does not have any data, as checked instep 82, the flow returns back to step 80, and the monitoring continues.Once the FIFO queue 28D does have data, which, in this example, wasdeposited by the HDLC processing circuit 22C, the flow continues to step84, where the data is read by the SONET processor 22D, and operatedthereon. In step 84, not all of the data in the data packet must bewritten prior to the processor 22 beginning its operations.

[0034] While the SONET processor 22D is still reading and operating onthe particular data packet, the flow loops between steps 84 and 86. Oncethe SONET processor 22D finishes operating on the data, it is ready towrite the data to the next FIFO queue 28E. Prior to writing the data tothe FIFO queue 28E, however, the SONET processor 22D checks to verifythat the FIFO queue is not full, by checking the full flag 14 of thequeue in step 88. If the FIFO queue 28E is full, the flow stopsprocessing and delays for a short time in step 90, and then returns tostep 88 to check the full flag 14 again. When the full flag 14 indicatesthat the FIFO queue 28E can accept data, the data is written into thequeue in step 92. Of course, there are many ways to implement the flowshown in FIG. 4, and the shown method is not the only one that accordsto the invention.

[0035] Although FIGS. 3 and 4 show examples of only the ingress stop andgo pipeline 23, the operation of the FIFO queues 28 is equallyapplicable on the egress stop and go pipeline 25. Because most of theegress processes 24 are simply the ingress processes 22 performed inreverse, the interaction between the egress processes 24 and the FIFOqueues 28 is either similar or identical, and embodiments of theinvention are equally applicable.

[0036] Also, only a limited number of processes 22 in FIG. 3 are shown,but many more ingress processes 22 and egress processes 24 are typicallyin a network processor 20. For instance there are processes that performheader insertions and deletions, and those that perform encapsulationsand decapsulations. Examples include VLAN, MPLS and TLS processing.Additionally, there are processes that perform Lookup Keys and returnCMD processes. In these processes, and address can generate a lookup keyby programmable microcode in addition or instead of a standard tablesearch. Also, they can execute a return CMD (after the lookup) toprocess the packet header that can also be controlled by programmablemicrocode. Other processes include CRC generation and validationprocesses. In the case of a CRC check, a process 22 may send the entirepacket from the process into the following FIFO queue 28 prior toperforming the necessary functions on the CRC. Other processes caninclude IPv4 and IPv6 header checksum calculation and validation. Stillother processes can include packet filtering, and QOS processing. All ofthese processes, and others, and future processes, are compatible withembodiments of the invention, and are specifically contemplated.

[0037] The system described above can use dedicated processor systems,micro controllers, programmable logic devices, or microprocessors thatperform some or all of the processing functions. Some of the operationsdescribed above may be implemented in software and other operations maybe implemented in hardware.

[0038] Of course there can be many or few FIFOs in the networkprocessor. It may be beneficial have some of the processes communicatedirectly with one another without using a FIFO queue, while others arebetter suited to communicate via FIFO queues. As always, implementationis left to the system designer, and many of the specific details may bebest determined empirically.

[0039] For the sake of convenience, the operations are described asvarious interconnected functional blocks or distinct software modules.This is not necessary, however, and there may be cases where thesefunctional blocks or modules are equivalently aggregated into a singlelogic device, program or operation with unclear boundaries. In anyevent, the functional blocks and software modules or described featurescan be implemented by themselves, or in combination with otheroperations in either hardware or software.

[0040] Having described and illustrated the principles of the inventionin a preferred embodiment thereof, it should be apparent that theinvention may be modified in arrangement and detail without departingfrom such principles. Claim is made to all modifications and variationcoming within the spirit and scope of the following claims.

What is claimed is:
 1. A network device, comprising: a port adapted tobe coupled to a computer network and configured to accept a stream ofdata grouped in packets; a first process coupled to the port andconfigured to modify the data packets; a FIFO queue coupled to the firstprocess and structured to store modified data packets output by thefirst process; and a second process coupled to the FIFO queue andconfigured to automatically read data from the FIFO queue after data hasbeen deposited into the FIFO queue.
 2. The network device of claim 1,wherein the second process is configured to read data from the FIFOqueue before an entire data packet has been deposited into the FIFOqueue.
 3. The network device of claim 1, wherein the second process isconfigured to begin processing data retrieved from the FIFO queue beforeit retrieves an entire data packet from the FIFO queue.
 4. The networkdevice of claim 1, wherein the second process is configured to monitoran empty flag of the FIFO queue, and, when the empty flag signals thatthe FIFO queue is not empty, to read data from the FIFO queue.
 5. Thenetwork device of claim 1, wherein the first process and the secondprocess are configured to operate in different clock domains.
 6. Thenetwork device of claim 5, wherein the first process and the secondprocess are configured to operate at a same clock speed.
 7. The networkdevice of claim 1, further comprising a communication line coupled tothe first process and the second process and configured to transfer datafrom one process to the other.
 8. The network device of claim 1, whereinthe first process is configured to check a full flag on the FIFO queuebefore storing data in the FIFO queue.
 9. The network device of claim 1,wherein the FIFO queue comprises: a write bus coupled to a write port; aread bus coupled to a read port; a plurality of storage locations tostore data each coupled to the write port and the read port; a writepointer configured to indicate in which of the plurality of storagelocations the next data written to the write port will be stored; and aread pointer configured to indicate from which of the plurality ofstorage locations the next data read from the read port will beretrieved.
 10. The network device of claim 9, further comprising: a fullflag configured to indicate when all of the plurality of storagelocations have data stored in them; and an empty flag configured toindicate when none of the plurality of storage locations have datastored in them.
 11. The network device of claim 1, wherein the firstprocess is configured to perform a header deletion.
 12. The networkdevice of claim 1, wherein the first process is configured to perform aCRC validation.
 13. The network device of claim 1 wherein the firstprocess and the second process are both ingress processes, the networkdevice further comprising: a switch fabric coupled to the second ingressprocess; a first egress process coupled to the switch fabric andstructured to accept a stream of data grouped in packets; a second FIFOqueue coupled to the first egress process and structured to store dataoutput by the first egress process; and a second egress process coupledto the second FIFO queue and configured to automatically read data fromthe second FIFO queue after data has been deposited into the second FIFOqueue.
 14. A network device, comprising: an input port adapted to becoupled to a computer network and structured to receive packets of data;a first FIFO queue coupled to the input port and structured to store thereceived packets of data; a first ingress process coupled to the firstFIFO queue, the first ingress process configured to monitor an emptyflag on the first FIFO queue and read data from the first FIFO queuewhen the empty flag signals there is data in the first FIFO queue; asecond FIFO queue coupled to the first ingress process and structured tostore data from the first ingress process; a second ingress processcoupled to the second FIFO queue, the second ingress process configuredto monitor an empty flag on the second FIFO queue and read data from thesecond FIFO queue when the empty flag signals there is data in thesecond FIFO queue; a switch fabric coupled to the second ingressprocess; a third FIFO queue coupled to the switch fabric and structuredto accept a stream of data from the switch fabric grouped in datapackets; a first egress process coupled to the third FIFO queue andstructured to monitor an empty flag on the third FIFO queue and readdata from the third FIFO queue when the empty flag of the third FIFOqueue indicates that there is data in the third FIFO queue; a fourthFIFO queue coupled to the first egress process and structured to storedata output by the first egress process; and a second egress processcoupled to the fourth FIFO queue and configured to monitor an empty flagon the fourth FIFO queue and read data from the fourth FIFO queue whenthe empty flag of the fourth FIFO queue indicates that there is data inthe fourth FIFO queue.
 15. The network device of claim 14, wherein thesecond ingress process is configured to read data from the second FIFOqueue before an entire data packet has been stored into the second FIFOqueue.
 16. The network device of claim 14, wherein the second ingressprocess is configured to begin processing data retrieved from the secondFIFO queue before it retrieves an entire data packet from the secondFIFO queue.
 17. The network device of claim 14, wherein neither thefirst or second ingress processes nor the first or second egressprocesses operate in the same clock domain.
 18. The network device ofclaim 14, further comprising a first communication line coupled to thefirst ingress process and the second ingress process and configured totransfer data from one ingress process to the other separate from thesecond FIFO queue.
 19. The network device of claim 18, furthercomprising a second communication line coupled to the first egressprocess and the second egress process and configured to transfer datafrom one egress process to the other separate from the fourth FIFOqueue.
 20. The network device of claim 14, wherein one or more of theFIFO queues comprise: a write bus coupled to a write port; a read buscoupled to a read port; a plurality of storage locations to store dataeach coupled to the write port and the read port; a write pointerconfigured to indicate in which of the plurality of storage locationsthe next data written to the write port will be stored; a read pointerconfigured to indicate from which of the plurality of storage locationsthe next data read from the read port will be retrieved; a full flagconfigured to indicate when all of the plurality of storage locationshave data stored in them; and an empty flag configured to indicate whennone of the plurality of storage locations have data stored in them. 21.A method of processing data in a network device, comprising: readingdata from a first queue; beginning performing a data operation whenenough data has been read from the first queue by a first process tobegin performing the data operation; completing the data operation bythe first process; storing the data that has been operated on by thefirst process into a second queue; monitoring a second queue by a secondprocess to determine when data has been stored in the second queue; andretrieving data from the second queue by the second process when datahas been stored in the second queue.
 22. The network device of claim 21,wherein the second process is configured to read data from the secondqueue before an entire data packet has been deposited into the secondqueue.
 23. The network device of claim 21, wherein the second process isconfigured to begin processing data read from the second queue before anentire data has been read from the second queue.
 24. The method of claim21 wherein monitoring a second queue by a second process comprisesmonitoring an empty flag of the second queue.
 25. The method of claim21, wherein the first process and the second process operate indifferent clock domains.
 26. The method of claim 21, further comprisingcommunicating between the first process and the second process over acommunication line separate from the first queue and the second queue.27. The method of claim 21 wherein storing the data that has beenoperated on by the first process into a second queue comprises: checkinga full flag on the second queue; and when the full flag indicates thatthe second queue is not full, storing the data into the second queue.28. The method of claim 21, wherein at least one of the queuescomprises: a write bus coupled to a write port; a read bus coupled to aread port; a plurality of storage locations to store data each coupledto the write port and the read port; a write pointer configured toindicate in which of the plurality of storage locations the next datawritten to the write port will be stored; a read pointer configured toindicate from which of the plurality of storage locations the next dataread from the read port will be retrieved a full flag configured toindicate when all of the plurality of storage locations have data storedin them; and an empty flag configured to indicate when none of theplurality of storage locations have data stored in them.
 29. The methodof claim 21, further comprising deencapsulating data retrieved from thesecond queue.
 30. The method of claim 21, further comprising validatingthe CRC data of a data packet retrieved from the second queue.
 31. Themethod of claim 21, further comprising performing a checksum operationon data retrieved from the second queue.
 32. The method of claim 21,further comprising looking up key values for data retrieved from thesecond queue.
 33. A method of processing data in a network device,comprising: performing a data operation, by a first process, on datawithin a data packet; checking a full flag on a queue that is coupled tothe first process to determine if the queue is full of data; storing theoperated-on data in the queue when the full flag indicates that thequeue is not full; monitoring an empty flag of the queue by a secondprocess to determine when data has been stored in the queue; retrievingdata from the second queue by the second process when data has beenstored in the second queue; and beginning operating on the data from thesecond queue when enough data has been retrieved from the second queue.34. The method of claim 33, wherein operating on the data from thesecond queue comprises stripping a header from data retrieved from thesecond queue.
 35. The method of claim 33, wherein operating on the datafrom the second queue comprises performing a table lookup on dataretrieved from the second queue.
 36. The method of claim 33, whereinoperating on the data from the second queue comprises performing a CRCvalidation on data retrieved from the second queue.
 37. The method ofclaim 33, wherein operating on the data from the second queue comprisesencapsulating data retrieved from the second queue into an encapsulateddata packet.
 38. The method of claim 33, wherein the first process andthe second process operate in different clock domains.
 39. The method ofclaim 33, further comprising communicating between the first process andthe second process over a communication line separate from the queue.40. The method of claim 33, wherein the queue comprises: a write buscoupled to a write port; a read bus coupled to a read port; a pluralityof storage locations to store data each coupled to the write port andthe read port; a write pointer configured to indicate in which of theplurality of storage locations the next data written to the write portwill be stored; a read pointer configured to indicate from which of theplurality of storage locations the next data read from the read portwill be retrieved a full flag configured to indicate when all of theplurality of storage locations have data stored in them; and an emptyflag configured to indicate when none of the plurality of storagelocations have data stored in them.